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Abstract: The increasingly widespread use of smartcards for a variety of sensitive applications, including digital 
signatures, creates the need to ensure and possibly certify the secure interoperability of these devices. Standard 
certification criteria, in particular the Common Criteria, define security requirements but do not sufficiently address 
the problem of interoperability. Here we consider the interoperability problem which arises when various appli- 
cations interact with different smartcards through a middleware. In such a situation it is possible that a smartcard 
of type S receives commands that were supposed to be executed on a different smartcard of type S f . Such "ex- 
ternal commands" can interleave with the commands that were supposed to be executed on S. We experimentally 
demonstrate this problem with a Common Criteria certified digital signature process on a commercially available 
smartcard. Importantly, in some of these cases the digital signature processes terminate without generating an error 
message or warning to the user. 
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1 Introduction 

Smartcards (SC) are becoming increasingly popular 
in many countries and are deployed, for example, as 
credit cards, health cards and electronic identification 
documents. With these devices users control highly 
sensitive information and may perform security tasks 
such as electronic authentication and digital signature. 
As the importance and world-wide spread of SCs in- 
creases, the interoperability of these devices becomes 
more important along with their security in environ- 
ments where SCs from different manufacturers and is- 
suers are used at the same time. 

The Common Criteria (CC) O and the CWA 
14169 L2J standards are used to certify the correct be- 
havior of a SC in a well defined environment, i.e. for 
a specific target of evaluation (TOE). The TOE is pre- 
cisely described and usually comprises a specific mi- 
croprocessor, a specified firmware and specified mid- 
dleware HI; however, environments where different 
SCs are used at the same time are usually different 
from the TOE. In particular, a SC could be confronted 
with commands from different processes, be it acci- 
dentally, on purpose or during an attack. Trusted SC 
interoperability, therefore, requires a careful analysis 
of how SCs operate in such situations and the consid- 
eration of these results in the design of interoperable 
systems. 



One goal of current research and development 
efforts regarding SC interoperability is to create a 
framework that enables the concurrent use of differ- 
ent SCs. These efforts focus on diverse topics such 
as standardization El, H, Q, architectures for SC 
based authentication services O, and open protocols 

However, interoperability problems emerge al- 
ready with the attempt to recognize what type of SC is 
actually used. In practice, this is currently done by de- 
tecting the presence of certain applications on the SC 
H). Deducing the SC type from such information is, at 
its best, an indirect method which might not uniquely 
identify the SC type, and leave it prone to potential at- 
tacks. If the SC type is incorrectly identified, "external 
commands" will be sent to the SC. Here, we define an 
"external command" as an Application Protocol Data 
Unit (APDU) sequence that does not correspond to the 
regular APDU sequence supplied to the SC in the exe- 
cutable code of the middleware originally used during 
the security certification (e.g. according to CC). In a 
setting where different SCs interact with applications 
via a middleware, APDUs that are supposed to be de- 
livered to a certain SC type S might be received by a 
SC of type S' (e.g., due to routing errors). In such sit- 
uations "external commands" can interleave with reg- 
ular commands. 



References (9|, iflOll study the behavior of com- 
mercial signature SCs during the sequential steps of 
a digital signature process. First the APDUs sent - 
in the setting used for the CC certification - from the 
middleware to the SC were identified. Using a model 
checking approach, the SCs were then targeted with 
modified APDUs during the digital signature process 
of a fixed document. The experiments showed that 
certain modified commands are accepted by the SCs 
without errors being generated and demonstrated that 
CC certification is not sufficient to address the SC in- 
teroperability problem. 

In this work we address the problem of interleav- 
ing commands for SC interoperability by analyzing 
the situation in which different applications interact 
with SCs via a middleware. A CC certified digital 
signature process on a commercially available SC is 
then tested to demonstrate the relevance of this prob- 
lem experimentally. Finally, we discuss the complex- 
ity of the underlying issues and how the experimental 
test setup may be improved in the future to identify 
and prevent potential interoperability problems of this 
kind. 



2 The Interoperability Problem: In- 
terleaving Command Sequences 

To address the interoperability problem on a funda- 
mental level, we consider a straight-line program Pi 
with steps Si 5 i, 5i } 2, Sij. It is assumed that the 
straight line program Pi has been certified to produce 
a correct result if the sequence of commands Ci } i, 
Ci } 2, Cij originally associated with these steps is 
executed in the correct order and without modifica- 
tions on a SC of type S. For example, the command 
sequence Ci 5 i, Ci i2 , could match the one sup- 

plied to S in the executable code of the middleware 
that was used for CC certification. We call a com- 
mand Cij "globally legal" if it is processed in step 
Si j of program Pi on SC of type S and the process Pi 
has been certified on S. 

In an environment where several applications in- 
teract with SCs via a middleware, commands from an- 
other straight line program P2 may interleave with the 
commands from Pi on S. Here P2 is a straight line 
program for another SC type S' with steps £2,1, £2,2, 

S 2 ,k and commands C 2 ,i, C 2 ,2, C 2 ^ k . Fig. Q] 
illustrates the situation and shows how SC S receives 
interleaving commands associated with different steps 
of the two digital signature processes Pi and P 2 . 

We will now analyze this SC interoperability 
problem in more detail, and in particular we distin- 
guish the following cases: 
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Figure 1: Two concurrent signing sessions 

1. In step Si j of Pi, SC S receives command Cij 
and processes it without error. The digital sig- 
nature process makes a correct transition to step 

Sij+i- 

2. In step Si j of Pi, SC S receives command C 2 ,i 
corresponding to step S 2 ,i of P 2 and correctly 
generates an error. At this point the error can 
be detected and digital signature process can be 
interrupted. 

3. In step Si j of Pi, SC S receives command C 2 ,i 
corresponding to step S 2 ,i of P 2 and processes 
it without generating an error, i.e. the SC rec- 
ognizes this command as "locally legal". How- 
ever, in this case, C 2 ,i is not globally legal. We 
refer to this situation as an "anomaly" since it is 
unknown how the overall signature process will 
be affected. The program may now potentially 
make a transition to any step of the two programs 
PiorP 2 . 

The first case simply describes the correct pro- 
cess. In the second case, the digital signature process 
may be interrupted, but the important point is that an 
error is generated and this error can be detected by 
the middleware. The interoperability environment can 
then be designed to handle such situations appropri- 
ately. The third possibility, however, poses the real 
problem for trusted SC interoperability: the "certi- 
fied" and, therefore, trusted process has been modi- 
fied but no error message has been generated. One 
anomaly can potentially be followed by several others 
and finally the digital signature process may terminate 
with a questionable result. Without receiving an error 
or a warning, a user cannot know whether all steps in 



the digital signature process were completed correctly 
or whether there have been one or more anomalies. 

In the following we demonstrate experimentally, 
with a commercially available CC certified SC for 
digital signature, how commands from a different 
straight line program may interleave with the origi- 
nal one. Furthermore we present one example where 
even though an error is generated, an external com- 
mand that intersects the original program can render a 
SC inappropriate for further use. The testing environ- 
ment developed for this purpose, as well as relevant 
details about SCs are described in the next section. 
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Figure 2: Architecture of the Crypto Probing System 



3 The Testing Environment 

In our experiments, we study two commercially avail- 
able SCs from two different manufacturers. The core 
of a SC is its microprocessor, which contains on 
board, a cryptographic processor, a small EEPROM 
random access memory 64 KBytes), an operating 
system and a memory mapped file system ifTTTl . The 
microprocessor is customized (masked) in order to ex- 
ecute APDU sent from external software applications 
through a serial communication line. 

The ISO 7816 standard Q, specifies the set of 
APDU that can be implemented by any compatible 
SC microprocessor. In particular, an APDU consists 
of a mandatory header of 4 bytes: the Class Byte (cla), 
the Instruction Byte (ins) and two parameter bytes (pi, 
p2). The header can be followed by a conditional body 
of variable length, which is composed by the length 
(in bytes) of the data field (lc), the data field itself and 
the maximum number of bytes expected in the data 
field of the response (le). Responses to any APDU are 
encoded in a variable length data field and two bytes 
mandatory return codes. 

To probe and analyze the SC behavior we have 
developed a Crypto Probing System (CPS) whose 
overall architecture is shown in fig. [2| As each SC 
uses a different APDU sequence in the digital sig- 
nature process, the CPS is designed to interface with 
both SCs used in this project. Effectively, it therefore 
acts as a middleware between the external applications 
and the real SCs. 

The CPS is able to translate its simplified instruc- 
tions to the corresponding sequence of APDUs (cla, 
ins, pi, p2, length and values of the possible annexed 
data buffer) to be sent to the connected physical SC 
and to translate the SC responses in a common for- 
mat. Moreover, to further simplify the interface with 
the SC, the CPS is given the globally legal APDUs 
to be sent in each step of the digital signature process 
(SC commands flow), and the CPS is able to generate 
alternate command sequences to test the SC responses 



in different situations. This way, the CPS offers a sim- 
ple interface for testing applications verifying process 
correctness and robustness on different physical de- 
vices and in the presence of interleaving command se- 
quences. 

The CPS can be invoked via command line, to in- 
teractively test the command sequences, or used as a 
daemon, which stays in execution and accepts com- 
mands on TCP/IP connections. The commands sent 
via command line are parsed and interpreted by the 
CPS based on SC library. The elementary instruction 
of the CPS is made by a single APDU. 

4 Results 

In this section we present the main experimental re- 
sults of this work. We use the CPS testing envi- 
ronment to show how external commands interleave 
with the globally legal commands in a SC based dig- 
ital signature process. The experiments are carried 
out with two CC certified SCs from STM-Incrypto34 
and Infineon-CardOs JT2l . 021. The main results are 
shown in figs. [51 01 and [5] and tables Q] and [2 
The left (right) column of fig. [3] presents the 10 (5) 
steps of the digital signatures processes with the In- 
crypto (Infineon) SCs. Note that we do not count the 
initial "RESET" and have given similar steps in both 
processes the same label, although the APDUs asso- 
ciated with these steps may be different. 

Fig.[3]shows how the commands "Get Challenge" 
and "Give Challenge" from steps (1,5) and (1,6) 
from process P\ interleave with steps (2, 1) to (2, 5) 
of process P2 on the Infineon SC (central column in 
fig. [3]). No error message is generated, and the pro- 
cess P2 terminates as if no interference occurred. In 
fact, our experiments show that "Get Challenge" and 
"Give Challenge" commands of process P\ can inter- 
leave with process P2 before and after all of its steps. 
In this case, the interleaving commands of two glob- 
ally legal digital signature processes create a result 
whose trustworthiness has not been assured. Because 
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Figure 3: Two concurrent signing sessions, Infineon 
Smartcard 



a user cannot distinguish this situation from one in 
which no anomaly occurred, this problem might un- 
dermine the overall trustworthiness of SC use in an 
interoperable environment. Furthermore, sending the 
"Get Challenge" and "Give Challenge" commands re- 
peatedly to the SC could be used by an attacker to put 
a digital signature process effectively on hold. 

The results shown in fig. |4] were obtained with 
the Incrypto SC. As above, Pi represents the digi- 
tal signature process associated with this SC and the 
globally legal APDUs of each step are given in ta- 
ble Q] (here RN is short for "random number"). Pro- 
cess P2 contains APDUs that are either slightly or 
substantially different from the globally legal APDUs 
in Pi (see table [2 the modified parts are printed in 
bold font). In particular, certain APDUs are not doc- 
umented for the Incrypto SC: these APDUs are there- 
fore labeled as "undefined". The exact sequence of 
APDUs in P2 is not part of a single digital signature 
process on any SC we are aware of. Nevertheless, 
these commands could well be part of such processes 
implemented on one or several different SCs. 
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Figure 4: Two concurrent signing sessions, Incrypto 
Smartcard 



The command sequence executed in our experi- 
ments is shown in the central column of fig. |4| Al- 
though this executed process contains six additional 
commands (five of them "undefined") and four mod- 
ified commands, it terminates without any error mes- 
sage. In addition, the sequence can be looped back 
to the first node (1,1) "Master File" after any step 
of the executed process and afterwards continue until 
the end. These examples show how drastically digi- 
tal signature processes can be modified via interleav- 
ing commands without the associated anomalies being 
recognized. An interoperable environment that does 
not address this issue may not be considered trustwor- 
thy and may have vulnerabilities that potential attack- 
ers could seek to exploit. 



Table 1: Globally legal APDUs of process P 1 in fig.H 
(hexadecimal representation) 
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Table 2: Globally legal and modified APDUs of the 
executed process of fig. 0] (hexadecimal representa- 
tion) 



Node 


Globally legal and modified APDUs 
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Finally, we would like to point out a problem 
caused by interleaving commands that has consider- 
able consequences even though an error is generated. 
In this experiment (shown in fig. [5]), P2 contains the 
"MSE Erase" command. This command is usually not 
part of a digital signature process as it erases the Se- 
curity Environment Object (SEO); however, it is con- 
ceivable that this command is used by an application 
interacting with the middleware for some purpose. It 
may then accidentally, or even in an attack, interleave 
with a digital signature process like P\. We observe 
experimentally that "MSE Erase", executed as shown 
in the central column of fig. erases the SEO on the 
SC without warning, and the digital signature process 
generates an error after the next step S\$. The digital 
signature function of the SC is herewith permanently 
destroyed and a physical replacement of the SC is re- 
quired. In principal, such vulnerability could be sys- 
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Figure 5: Signing session with interleaving "MSE 
Erase" command 

tematically exploited in an attack on all SCs issued by 
the digital signature service provider because neither 
PIN nor PUK is required to execute the "MSE Erase" 
command. 

5 Conclusion 

The experiments described above show that the prob- 
lem of interleaving command sequences is serious and 
that it must be addressed to ensure a secure and trust- 
worthy environment for SC interoperability. 

As stated in the introduction, in previous work 
ED, OH a C-Murphi model checker [14] has been 
used to test SC behavior in the presence of disturbed 
commands. Model checking can address extended 
systems which can assume millions of different states 
[1131 and can in principal be used to identify anoma- 
lies. However, the complexity of the verification in- 
creases exponentially if interleaving commands are to 
be taken into account: assume that for every step of 
two digital signature processes, the input command 
has only a 16 bits and assume that the two signa- 
ture processes consist of 10 steps each. Even under 
this strong simplification, a brute force model checker 
may be required to make more than (^) * 2 16+16 tests. 
This is due to the fact that in this approach all pos- 
sible sequences that can be obtained by mixing the 
two signature processes are generated. Note that in an 
interoperable environment, possibly tens, if not hun- 
dreds, of applications may interact concurrently with 
various SC types via some middleware. As a result, 
a brute force model checking approach is clearly not 



a viable solution, especially if it is operated on real 
SCs as illustrated in the experiments described above 
where the execution of a single command can take up 
to 1 second. 

In future research, we plan to extend the model 
checking approach to avoid brute force testing and to 
identify errors and anomalies effectively. This can be 
done if one prevents the model checker from search- 
ing through all possible sequences of anomalies and 
errors by taking the results of the already existing CC 
certification into account. Such an efficient model 
checker can then be integrated into a middleware as 
a "watch-dog" to identify an anomaly as it occurs 
and to prevent computational chains with two or more 
anomalies. In this case, it will be possible to extend 
the CC to certify the anomaly-free interoperability of 
several SC applications interacting via a middleware 
with different SC types. 
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